Master thesis "Salary in the fire department"

Problem

LODUR offers fire department administration functions. This mainly includes the following areas: Administration for firefighters, salary, operation reporting, material management, course registration and overview of training status. The module "Salary" causes B. Wahlstroem Engineering GmbH, a high support effort. In this module, the configuration of the salary rules is carried out, a task for which almost every fire department currently requires support. The client is therefore interested in reducing the number of support cases with a redesign of the module "Salary" or at best eliminating it completely. The reasons for the large number of support cases are on the one hand the strong distribution of individual settings to different windows and on the other hand the technical complexity of the salary rules. Every fire department has its own, sometimes completely different, salary rules.

In simple terms, the salary rules define different pay rates and the settlement type for different activities. The payroll type determines whether an activity is remunerated per hour, as a lump sum or in a mixed form. Pay rules are normally set up once. Adjustments are then made more or less often as required, for example, when a fire department adjusts its pay rates to reflect inflation.

Approach

The case study was worked out according to the principles and design activities of EN ISO 9241-210. This UCD process model was chosen because of its practical relevance. The principles and design activities of EN ISO 9241-2010 can be easily integrated into the "Requirements Engineering" and "Design" phases that are closely related to software development (Hübscher, 2011). The "Requirements Engineering" phase was adopted as the "Analysis" phase. In this phase the requirements were collected according to the aspects user, task, system and environment (Shackl, 2009). The design activities were structured in two phases. In the "Design" phase, a proposed solution in the form of a wireframe prototype was developed. The "Detailed Design and Evaluation" phase serves as preparation for the implementation. On the one hand, a usability test was carried out to check whether the solution proposal met the user's needs and on the other hand, the necessary documentation for the development was created. During the test run of the usability test, it was found that the HTML wireframe prototype could not be brought up to the level of the task "Set up salary rules" with a reasonable amount of time, so that no assistance from the test leader was necessary. Therefore it was decided to replace the phase "Detailed Design and Evaluation" with three further design iterations.

The Analysis Phase

The "Analysis" phase includes the identification of stakeholders, the definition of usability goals and the user-centric collection of requirements. The "Analysis" phase is divided into iterations in the sense of subphases. This means that the content of each iteration is different. The subphases nevertheless have an iterative character. The detailed planning of an iteration takes place at the end of the previous one.
The "Analysis" phase focuses on the user-centred analysis method ethnographic interviews according to Cooper et al (2010) and an online questionnaire.

Design Phase

The "Design" phase is concerned with the development of a proposed solution in the form of wireframe prototypes. In this phase several users took the time to evaluate our prototypes during a walkthrough. The "Design" phase is also divided into iterations in the sense of repeating a sequence of steps. This means that in each iteration the prototype is further developed based on the findings of the last iteration and each iteration is accompanied by an evaluation.

In-depth methodological study

Currently, there is no overall mapping between the aspects of the problem space and the final user interface design. In practice, the derivation of the design from the analysis results is mainly based on the experience of the interaction designers. Therefore, overcoming the gap between the problem and solution space is a kind of "magic".

Hübscher et al (2012) develop a mapping for this gap. This mapping model aims to provide a map as orientation between the problem and solution space.

In the context of the methodological deepening we compared two approaches to overcome the gap: First, we developed the design of the prototypes according to the principles of the structural and grid level according to Garrett (2012). Before the evaluation by means of a walkthrough we evaluated the prototype with the mapping model according to Hübscher et al (2012), the second approach with a mapping model.
The findings of the two evaluations show the difference in the prototype completeness of the respective approaches.

Results In-depth methodological study

For an assessment of the benefits of using a mapping model, we have made two hypotheses. The first hypothesis is that design iterations can be saved by evaluating prototypes with a mapping model. This is because in this case the prototypes are more mature in evaluations with the users due to the findings of a transient evaluation with the mapping model.

Two evaluations with the mapping model have produced a total of seven findings. One finding has shown that the first prototype does not meet the needs of the primary persona.

This would actually have meant postponing the walkthrough with a prototype V 2.0. For comparison, we nevertheless evaluated the prototype V 1.0 with a walkthrough, which confirmed this finding. If the results of the mapping model had already been included in V 1.0, we would now have
has already been at the V 2.0 level for the first walkthrough. This gives an indication that using the mapping model can save iterations. This is one of the open questions that arose from the comparison.

The second hypothesis is that evaluation with a mapping model yields different results than evaluation by walkthroughs. These seven findings from the evaluation with the mapping model are small compared to the approximately 15 findings from the walkthroughs with the same prototypes. Our hypothesis for this result is that a large part of the gap has already been overcome in a redesign task. This is because in a redesign, an existing system is analysed during the familiarisation phase, which already more or less covers the aspects of the problem area. This hypothesis is another open question.